Mobile communication systems, such as the universal mobile telecommunications system (UMTS) or SAE/LTE, can carry both voice and data traffic via fixed, wireless and satellite networks. These communication systems are incessantly evolving, thereby also developing and providing packet frameworks for the delivery of IP based, real-time, conversational or multimedia services. For instance, a service provided for mobile users is the Multimedia Broadcast/Multicast Service (MBMS), which has been standardized by the 3GPP (see 3GPP TS 23.246 v6.6.0: “Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description (Release 6)”, incorporated herein by reference, available from http://www.3gpp.org).
The MBMS service is a downlink multicast service for transmitting the same downlink data to a plurality of recipients through a radio network. The recipients typically share one radio channel in the radio network, a shared radio bearer for the reception of MBMS service data. The MBMS service supports the transmission of multimedia data such as real-time image and voice, or text.
Generally, mobile communications systems via which said service may be provided to users can be split into logically separated parts providing dedicated functionalities. These parts are usually called core network (CN) and access network (AN) with several access nodes. Particularly for wireless mobile communications systems the latter part is usually referred to as radio access network (RAN).
Typically, the network entities handling the network attach functionality are located in the core network of the mobile communications system. Entities in the radio access network and core network utilize defined interfaces to communicate between each other. In order to allow a distribution of the load caused by the mobile terminals across several core network entities, each radio access network entity handling the radio connection with the mobile terminal has to have a relation (i.e. interface) to a plurality of core network entities. As there are several radio access network entities deployed in a mobile communications system, this results in a many-to-many relation between the core network entities and the radio access network entities (see for example 3GPP TR 25.912, “Feasibility study for evolved Universal Terrestrial Radio Access (UTRA) and Universal Terrestrial Radio Access Network (UTRAN)”, version 7.0.0, available at http://www.3gpp.org and being incorporated herein by reference).
Considering the deployment of a mobile communications system in a large area, e.g. a whole country, it becomes obvious that a many-to-many relation cannot exist between all radio access network entities and all core network entities. As transport network connectivity has to be regionally or logically restricted, e.g. due to security reasons or due to other network operational reason, only a subset of all radio access network entities might have an interface to a subset of all core network entities. All those entities with an interface between them can be considered as being part of a logic region within the entire mobile communications network, which is typically called a pool area.
Taking into account network deployment aspects, such a pool area consists of a number of radio access network entities, which are geographically related to one or several core network entities, and where an interface exits between each entity of that pool area. Further, considering network deployment aspects it could be the case that different pool areas overlap each other (see for example 3GPP TR R3.018, “Evolved UTRA and UTRAN; Radio Access Architecture and Interfaces”, version 0.4.1, available at http://www.3gpp.org and being incorporated herein by reference).
This might be required in order to avoid excessive signaling, which would occur when a mobile terminal is moving along a hard border between different pool areas. In such a case the mobile would frequently switch the association from one to the other pool area due to varying signal strengths received from the respective radio access network entities. Such a switch of association would however require some signaling to update context state information maintained in the network. The deployment of overlapping pool areas introduces some kind of hysteresis for this kind of procedure avoiding the need for frequent updating of the context state information.
Another aspect for configuring overlapping pool areas is the possibility to separate the overall load according to different terminal moving pattern, e.g. considering multiple pool areas where each covers a separate residential area and all cover the same city centre (see for example 3GPP TS 23.236, “Intra-domain connection of Radio Access Network (RAN) nodes to multiple Core Network (CN) nodes”, version 6.3.0, available at http://www.3gpp.org and being incorporated herein by reference).
Traditionally (also in 3GPP SAE/LTE systems), the cellular networks are split into a control plane (also denoted C-plane) handling all control information and procedures, and a user plane (also denoted U-Plane) handling the actual user data traffic, which also applies for the multicast architecture. The invention assumes that the multicast control plane can be handled by all core network control plane entities, which are assigned to the mobile terminals during network attachment or mobility. With respect to the SAE/LTE system the Mobility Management Entity (MME) performs the core network control plane functionality. For exemplary purposes all MMEs that also contain multicast management functionality may be referred to as a Multicast-MME (M-MME). On the other hand, for the SAE/LTE system the core network user plane functionality is contained in the User Plane Entity (UPE). It is assumed that at least one UPE provides user plane functionality for a multicast service and may be referred to as a Multicast-UPE (M-UPE), if it is selected by an M-MME to handle the multicast service data. Further, depending on the pool area size and/or MME(s)/UPE(s) capability, at least one M-UPE per pool area may be selected for a multicast service.
From the perspective of a mobile terminal, the M-MME is the same MME as assigned during network attach or mobility. However, it may be possible that the M-UPE serving point-to-multipoint (p-t-m) services is different from the UPE assigned for point-to-point (p-t-p) services. Despite this, for multicast services there is no direct relation between the mobile terminal and the M-UPE, i.e. the terminal does not maintain a user plane bearer to the M-UPE. In fact, the multicast service data is delivered from the M-UPE to the access nodes (eNodeBs), which broadcast the data to all mobile terminals present in their respective service area. E.g. IP multicast transport may be utilized in the network between the M-UPE and access nodes for transmission of the multicast service data.
An exemplary communication system is shown in FIG. 1 being composed of several pool areas 111, 121, 131, which respectively overlap each other. It is assumed that there are one or more access nodes (eNodeBs 114, 1115) assigned to only Pool Area 1 111, one or more access nodes (eNodeB 116) assigned to Pool Area 1 111 and Pool Area 2 121 simultaneously, and one or more access nodes (eNodeB 124) assigned to Pool Area 2 121. Similarly, eNodeB 125 belongs to Pool Area 2 121 and to Pool Area N 131. As apparent from FIG. 1, those access nodes 116, 125, located in the overlapping areas of two neighbouring pool areas, have direct connectivity to the core network entities of both pool areas. On the other hand, eNodeBs 114, 115, 124, 134 that are not located in the overlapping regions only have direct connectivity to the core network entities of their corresponding pool area.
It may be further assumed for exemplary purposes that the core network entities, i.e. the mobility management entities and the user plane entity of a respective pool area are interconnected via interfaces for communication and signaling. Further, the core network entities may also be connected to the different access nodes assigned to each pool area. For simplicity, FIG. 1 shows that a multicast service is provided via a single user plane entity 113, 123, 133 in a respective pool area. However, it is of course also possible to have more than one user plane entity providing multicast service data to the respective access nodes (here eNodeBs) of a pool area in order to have redundancy in the network. Similarly, only one MME 112, 122, 132 is assumed to be located in each pool area, though the provision of more mobility management entities per pool area is feasible and probable. For exemplary purposes a BM-SC 101 (Broadcast/Multicast Service Center) is shown, which could be the source of the multicast service to be provided to mobile terminals in the pool areas.
Moreover, for a better understanding of the invention the following paragraphs outline the procedures and steps for starting and terminating a multicast service in a communication system as also applicable to several embodiments of the invention described herein. Provision of multicast services typically comprises several phases, like subscription and service announcement, joining, session start and data transfer. Also for the termination of multicast services several phases can be identified, like session stop and leaving. From these phases, subscription, joining and leaving are typically performed individually per user. The other phases are typically performed on a service basis, i.e. for all users interested in the related service.
The subscription establishes the relationship between the user and the service provider, which allows the user to receive the related multicast service offered by the operator. The service announcement is used to distribute to users information about the service, parameters required for service activation (e.g. IP multicast addresses) and possibly other service related parameters (e.g. service start time).
The joining is part of the service activation phase by which a subscriber joins (becomes a member of) a multicast group, i.e. the user indicates to the network that he/she wants to to receive a specific multicast service. The user and/or UE choose the joining time possibly in response to a service announcement. This can be any time before, during or after the actual start of the multicast service. In case the service activation phase happens before the service start, this typically deploys relevant registration information in the network and reserves required resources without actually allocating them.
Finally, session start is the point at which the multicast service data is ready to be sent. As indicated above, session start might occur independently of service activation by the users. It is the trigger for resource allocation and establishment in the network, i.e. comprising core network and radio network resources. Subsequently, the multicast service data can be transmitted to the users.
Complementary, session stop is the point of time at which there will be no more data sent for the multicast service. It triggers release of previously allocated resources in the network. The leaving is the process by which a subscriber leaves (stops being a member of) a multicast group, i.e. the user no longer wants to receive a specific multicast service.
During the time in which the service is provided to the subscribers, the mobile terminals may move away from the location at which the service initially started, and eventually leave the pool area. FIG. 2 illustrates the communication network and the corresponding user-plane connections necessary for ensuring service continuity of a service for the mobile terminal.
In particular, the service is at first started and provided to the mobile terminal 102 in Pool Area 1 111. Therefore, a user-plane is established between the mobile terminal and the service provider, SM-SC 101, via M-UPE 113, various routers 117 and access node 115 in Pool Area 1 111. As the mobile terminal is moving, it will eventually leave Pool Area 1 111 and enter Pool Area 2 121. In case only one UPE per multicast service per service area is used, the service data is forwarded by the M-UPE 113 of Pool Area 1 111 to the new M-UPE 123 of Pool Area 2 121. In turn, the service data is then provided to the mobile terminal 102 via routers 127 and access node 124 of Pool Area 2 121. Similarly, upon the mobile terminal 102 changing again the pool area from Pool Area 2 121 to Pool Area N 131, the service data is further forwarded from M-UPE 123 to the new M-UPE 133 of Pool Area N 131. The mobile terminal 102 then receives the multicast service in Pool Area N 131 via routers 137 and access node 134.
As apparent from FIG. 2 the path lengths necessary to provide the mobile terminal 102 with the multicast service are continually increasing due to the movements of the mobile terminal 102 to neighbouring pool areas. Accordingly, data delays for the provided service increase as well, thereby complicating the delivery of synchronised data to multicast users.
Furthermore, the re-assignment of entities in the core network, e.g. UPE, to the mobile terminal can occur only after the mobile terminal moves to the new pool area, since the mobile terminal has to provide the network resource identifier to the RAN once it moves to the new pool area. On the other hand, static assignment requires an exceeding amount of effort and maintenance of databases at the core network entities, thereby reducing the flexibility of re-locating to a possible better entity as well.